One way to improve data access times in a relational database system is to pre-load into volatile memory either an entire database object, or portions thereof. For example, operations that involve a table T1 may be performed faster if a copy of table T1 has been pre-loaded into volatile memory. Techniques for pre-loading database objects, or portions thereof, into volatile memory are described, for example, in U.S. Pat. No. 9,292,564 (the “Mirroring Patent”), which is incorporated herein by this reference.
Within volatile memory, in-memory copies of database objects (or portions thereof) are stored in In-memory Units (“IMUs”). The data stored in an IMU is referred to as a chunk. Any given chunk may include all data from a database object or a subset of the data from a database object. For example, data from a table T1 may be divided into four chunks, which may be respectively loaded into four distinct IMUs.
As explained in the Mirroring Patent, the format of data in an IMU may be different than the format in which the same data is stored on persistent storage. For example, the format used to store data from table T on disk (the “persistent-format”) may be row-major, while the format used to store the same data in volatile memory (the “mirror-format”) may be column-major. In addition, some or all of the data within an IMU may be compressed. When some or all of the data within an IMU is compressed, the IMU may be referred to as an In-memory Compression Unit (“IMCU”).
The amount of data that can be loaded into IMUs is constrained by the amount of available volatile memory. Consequently, to effectively leverage the IMUs, it is necessary to intelligently select which elements (e.g. tables, partitions, columns, etc.) are loaded into the IMUs. The database elements that are selected for loading into IMUs are referred to herein as the “to-be-mirrored elements”.
Ideally, at any given time, the volatile memory that is available for storing IMUs will be filled with chunks from the database elements that are currently being accessed the most heavily. Unfortunately, which elements are most heavily accessed changes over time. For example, during a period in which table T1 is being accessed heavily, mirroring chunks of table T1 in volatile memory may achieve the greatest benefit. However, at a later time when table T1 is not being accessed, it may be more beneficial to use the volatile memory that was occupied by the chunks of table T1 to cache chunks of a different table T2 that is being more heavily accessed. Techniques for dynamically changing which database elements are mirrored in volatile memory are described in U.S. patent application Ser. No. 14/922,086, the entire contents of which are incorporated herein by reference.
Regardless of how the system determines the to-be-mirrored elements, it is possible that elements that were previously selected as to-be-mirrored elements are no longer selected as to-be-mirrored elements. Such elements are evicted from volatile memory to free up space for newly-selected to-be-mirrored elements. Once an element has been evicted from volatile memory, subsequent requests for data items in that element must obtain the data items in the persistent-format. Obtaining the data items in the persistent-format may involve reading the data items from disk, or accessing a copy of a disk block that has previously been loaded into a buffer cache. Accessing a mirror copy of the data items, in the mirror format, is no longer possible because the mirror copy has been evicted from volatile memory to make room for the currently selected to-be-mirrored elements.
Thus, using conventional techniques, the data items of an element are typically either available in a mirror format from very fast storage (volatile memory), or only available in the persistent-format (from disk or cache). This all-or-nothing approach to mirroring data is inefficient for systems that have one or more tiers of storage that have performance characteristics between volatile memory and magnetic disks.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.